\documentclass{article}
\usepackage[utf8]{inputenc}

\title{Software Engineering}
\author{Adrian.Nembach@uni-konstanz.de 01/842319\\Udo.3.Schlegel@uni-konstanz.de 01/840835\\Sirui.Liu@uni-konstanz.de 01/857316}
\begin{document}
\maketitle

\section*{Aufgabe 1}
\begin{enumerate}
\item In the Classical Code and Fix scheme you don't have to spend so much effort Specification and Desing etc. But the Weak point of Code and Fix quickly surface as the Programm grows. To overcome the Complexity and Size of a big Software Project, Industrial Methods or "Engineering" have to be introduced, so Design and other preparations become more and more important. \\\\
With the percentages above you see that the main programming of the program are less than half of the costs. To find the right requirements, to design a working concept for these requirements and to test the program need the biggest part of the money which is invested in a software program.\\\\
The work above needs experts in several fields, which can't be done by one Human, in contrast to an executable Programm. So a Software is more likely a Industrial Product than just an executable Programm.
\item If you had already spent much time and personal in developing a system and you write more and more code that has BUGs in the design and you are aware of it only at the end, you have redo more work and recode a lot more.
\end{enumerate}

\section*{Aufgabe 2}
\begin{itemize}
\item[Pros:]Performance: 1 second for any input that meets standard, $1-10^{-20}$ correctness
\item[Cons:]
\begin{enumerate}
\item No Robustness: System may crash on unexpected input
\item No Reliability: Programm only accepts input that satisfy particular conditions
\item No Correctness: Same as Reliability, Programm only accepts inputs that satisfy particular conditions, not generalized.
\item No Maintainability: For a new feature 80\% need to be rewritten
\item No Interoperability: Same as Maintainability, for a new interface 80\% need to be rewritten
\item No Reusability: As this Programm has no Correctness and Maintainability, it is a bad idea to write a Programm that is based or uses the output of this Programm
\end{enumerate}
\end{itemize}
Conclusion: This must be a Programm for Professional use in a single field where changes rarely take place. As it's Professional, the user does know exactly what he is doing. This Programm has one strength, that is it always takes only 1 second for a output with great accuracy, this is a efficiency where the Professional user can rely on. As it is for a single field of use where changes rarely take place, this software doesnt need an upgrade for a very long time.

\section*{Aufgabe 3}
\begin{enumerate}
\item Homezone definition ambigous: What is a home zone? - country? town? house? city? a fixed field?
\item Are this 3 cents per minute for all kinds of calls, how are for example international calls handled?
\item Charge by the full minute or when a new minute begins?
\item What happens if you start your call in your home zone and then walk/run/drive out of your homezone?
\item Can the user change the homezone without changing his phone number
\end{enumerate}
New defined Requirement: 
\begin{enumerate}
\item Every mobile phone number has a fixed so-called “homezone”.
\item The homezone mentioned in 1. is a city.
\item Within the homezone, a domestic phone call costs 3 cents per minute.
\item Outside the homezone, a domestic phone call costs 7 cents per minute.
\item Within the homezone, a international phone call costs X cents per minute (X refer to price list 1).
\item Outside the homezone, a international phone call costs X cents per minute (X refer to price list 2).
\item The money is charged by the beginning of every minute.
\item The user can change his homezone without changing his phone number.
\item The money which is charged during one phone call is always the same amount per minute, and is equal to the amount charged at the first minute.
\end{enumerate}

\end{document}